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Extensible Field Addressing 


Introduction 


This memo discusses the need for and advantages of the expression of 
addresses in a network environment as a set of fields. The suggestion 
is that as the network grows the address can be extended by three 
techniques: adding fields on the left, adding fields on the right, and 
increasing the size of individual fields. Carl Sunshine has described 
this type of addressing in a paper on source routing [1]. 


Motivation 
Change in the Host-IMP Interface 


The revised Host-IMP interface provides for a larger address space for 


hosts and IMPs [2]. The old inteface allowed for a 2 bit host field and 
a 6 bit IMP field. The new interface allows a 8 bit host field anda 16 
bit IMP field. In using the old interface it was common practice to 


treat the two fields as a single eight bit quantity. When it was 
necessary to refer to a host by number a decimal number was often used. 
For example host 1 on IMP 1 was called host 65. Doug Wells has pointed 
out some of problems associated with attempting to continue such useage 
as the new interface comes into use [3]. If a per field notation had 
been used no problems would arise. 


Some examples of old and new host numbers are: 


Host Name Host IMP old # new # 
SRI-ARC 0 2 2 2 
UCLA-CCN 1 1 65 65537 
ISIA 1 22 86 65558 
ARPA-TIP 2 28 156 131100 
BBNA 3 5 197 196613 


Multinetwork Systems 
The prospect of interconnections of networks to form a complex 


multinetwork system poses additional addressing problems. The new 
Host-IMP interface specification has reserved fields in the leader to 
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carry network addresses [2]. There is experimental work in progress on 
interconnecting networks [4, 5, 6]. We should be prepared for these 
extensions to the address space. 


The addressing scheme should be expandable to increase in scope when 
interconnections are made between complex systems. 


Multiprocessor Hosts 


There may be configurations of hardware that could be interfaced to a 
network as a single host that in fact contain multiple processors. 

Tasks could be associated with processors such that it is desirable to 
dispatch network messages associated with certain sockets or message-ids 
to certain processors. For example it might be desirable to service all 
Telnet use from one processor and all FTP use from a different 
processor. 


The addressing scheme should be expandable to explicitly address the 
fine structure within a host when that is desirable. 


Some examples where such fine structure addressing would have been 
useful in the ARPANET are: 


At ISI, we have the capability of emulating computers using the PRIM 
system [7]. For many applications it is desirable to add the emulated 
host to the network. Since the emulation is carried out under control 
of a program operating under Tenex, we have a host within a host. 
Extensible addressing of hosts would provide the necessary handle. 


SCRL once had a PDP-11 connected by VDH to an IMP at UCSB. It became 
necessary to add a second PDP-11 to the network. The two PDP-11s were 
already physically connected and it would have been a simple matter to 
have the first serve as a multiplexor for both. However, because of 
the limitations in the network addressing structure, there was no way 
to identify the two hosts to other sites on the network. A new IMP 
had to be installed! 


In many other cases, it is desirable to have two hosts share the same 
front end to the network. With the current limitation, one IMP port 
must be consumed for each host. 
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Proposal 


The necessary solution to the problem posed by the change in the 
Host-IMP inteface is to always represent the address by fields. This 
solution provides for a natural growth into an internetwork environment, 
and allows explicit addressing of the fine structure within a host if 
that is desirable. 


The fields should be written in a natural way, and i believe that means 
that the most general field should come first with additional fields 
specifying more and more details of the address. In the current case 
this would lead to the following fields: 


Network / IMP / Host / Message-Identifier 


A problem with simple field addressing is the desire to specify only the 
fields that are necessary given the local context. A program 
interpreting the address is then unsure what the first field represents. 
Some clues are needed in the address specification for correct parsing 
to be possible. Dave Crocker has described a syntax for a similar 
problem in network access of data [8]. 


Specific Sugestion 


Specifically i suggest that we adopt a field based extensible address 
scheme where each field is separated from its neighbors by a delimiter 
character and each field has a name. When an address is specified the 
name of the most general field must also be indicated. 


Definitions: 
<address> ::= <field-name> ":" <fields> 
<field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID" 
<fields> ::= <field> | <field> "/" <fields> 
<field> ::= a decimal number 
Examples: 


NET:1/3/5/7 names message-id 7 at host 5 on imp 3 in network 1. 


HOST:6 names host 6 on whatever imp this message originates on. 
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One might ask: What is all the fuss about, isn’t this a non-problem?, 
The answer is: Almost. There are very few places where any real 
difficulties arise, but we have to change the way we think about host 
addresses. The places where there is a problem are typically little 
used, except one. The place where humans will see a difficulty is in 
the TIP "open" command [9], and to a lesser extent the user Telnet and 
user FTP "connect" commands. Other places are in the MAIL netaddress 
field, the FTP "sock" command [10], the Telnet reconnection option [11], 
and in the NIC maintained list of official host names [12]. 


Conclusion 


The suggestion is that we adopt field based extensible addressing to 
provide for growth in three ways: 


(1) growth of the number of hosts and IMPs by allowing these fields to 
grow in size independently of each other; 


(2) growth in scope by the addition of fields on the left to provide 
for multinetwork systems; 


(3) growth in fine structure by addition of fields on the right for the 
implementation of hosts as mininetworks. 
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